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REMARKS 

I. Introduction 

This paper addresses the non-final Office Action of February 6, 2009, in connection 
with the above-captioned application. Claims 1, 3-28, 30-36, 38, 40, 42, and 44 are currently 
pending. Claims 1, 3-28, 30-36, 38, 40, 42, and 44 have been rejected. Claims 1, 3, 7-10, 15, 
20-23, 28, 30-32, 34-36, 38, 40, 42, and 44 are amended. Claims 46-55 are newly added. 
The present amendments and the new claims are supported by the original disclosure. No 
new matter has been added. In view of the foregoing amendments and the following 
remarks, it is respectfully submitted that all of the presently pending claims are allowable, 
and reconsideration of the present application is respectfully requested. 

II. Objection of Claims 2, 7, 9, 30, and 31 

Claims 2, 7, 9, 30, and 31 are objected to for containing informalities. The claims are 
amended herein in accordance with the Office Action's suggestions. It is noted, however, 
that claim 2 was previously canceled, and the objection to claim 2 is understood as an 
objection to claim 3. Accordingly, it is respectfully submitted that the grounds for the 
objection have been fully addressed and withdrawal of the rejection is respectfully requested. 

III. Rejection of Claims 28, 30, and 31 under 35 U.S.C. § 101 

Claims 28, 30, and 31 stand rejected under 35 U.S.C. § 101 as allegedly directed 
towards non-statutory subject matter. Specifically, the Office Action asserts that the 
"development module," "program compiler," and "message parser" of claim 28 "are neither 
computer components nor statutory processes, as they are not 'act' being performed. Such 
claimed computer programs do not define any structural and functional interrelationships 
between the computer program and other claimed elements of a computer which permit the 
computer program's functionality to be realized." 

Although the rejection is not agreed with, claim 28 is amended herein. As presented, 
claim 28 recites: 

28. (Currently Amended) A message processing apparatus, comprising: 
an application server including 

a development module stored on the application server, the development 
module configured to receive a markup language document and a template for a 
message data format in a program language, and configured to automatically generate 
a source code in the program language, the source code based on the markup language 
document and the template, the markup language document to be compliant with 
message rules associated with the OLTP language, and the source code configured to 
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enable direct transformation of a message between the program language and the 
OLTP language; 

a program compiler stored on the application server, the program compiler 
configured to compile the source code; and 

a message parser stored on the application server, the message parser 
configured to transform a payload message directly between the program language 
and the online transaction processing (OLTP) language using the compiled source 
code. 

Thus, claim 28 now recites an application server configured with various modules stored on 
the application server. It is respectfully submitted that claim 28, as amended, is drawn to 
statutory subject matter, as are claims 30 and 31 which depend from claim 28. Withdrawal of 
the rejection is respectfully requested. 

IV. Rejection of Claims 1, 3-28, 30-36, 38, 40, 42, and 44 under 35 U.S.C. § 103(a) 

Claims 1, 3-28, 30-36, 38, 40, 42, and 44 stand rejected under 35 U.S.C. § 103 over 
U.S. Patent App. Pub. No. 2003/0167444 ("Zorc"), in view of Michael Koch, Leverage 
legacy systems with a blend of XML, XSL, and Java ("Koch") and what is characterized in 
the office action as "Applicant's Admitted Prior Art." It is respectfully submitted that the 
present claims are patentable over the proposed combination of references for at least the 
following reasons. 

As an initial matter, Applicants do not agree or admit that Koch is a proper prior art 
reference. In addition, to the extent this citation is relied on in any way in the rejection, 
Applicants respectfully submit that the procedures set out in MPEP 2128 for electronic 
documents and the rules set out for reference citation in MPEP 707.05 must be complied 
with. Therefore, the rejection is traversed on these grounds. 

Applicants also do not agree or admit that any admission as to prior art was made, or 
that the material referred to as "Applicant's Admitted Prior Art" is prior art to the present 
application. The rejection is traversed on that ground also. 

As an introduction, some example embodiments of the present invention provide 
systems, architectures, and methods of processing messages which may provide for a 
significant reduction in the amount of time, labor, and expense required in the development 
of a message transformation process. In these example embodiments, source code in a 
program language is automatically generated. The source code may be compiled and the 
compiled source code may then be used to transform a payload message between a target 
language (which may be the program language) and an online transaction processing (OLTP) 
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language, and/or to transform response messages from the OLTP language to the target 
language. 

For example, in some example embodiments, a development module may receive a 
markup language document for each message in an OLTP language and may automatically 
generate source code from the markup documents. The markup language documents may be 
compliant with message rules, where the message rules may be associated generally with the 
OLTP language, and the source code may enable transformation of messages between the 
program language and the OLTP language. In addition, in example embodiments the 
development module may further include a stylesheet parser where the development module 
uses the stylesheet parser to automatically generate the source code based on both the 
markup language documents and the stylesheet data. For example, the stylesheet data 
may represent program templates for each type of message. For instance, the source code to 
be generated may depend on whether the message is a "request" message that must be 
encoded or a "response" message that must be decoded. Accordingly, the stylesheet data may 
be provided, partitioned into request stylesheet data and response stylesheet data. 



Accordingly, independent claim 1, as presented, recites: 

A method of processing messages comprising: 

receiving a markup language document describing a message, the 
markup language document being compliant with message rules associated 
with an online transaction processing ( OLTP) language; 

receiving a template for code in a program language, the template 
describing a data format for the message in a target p rogram language; 

automatically generating source code in the program language 
from the markup language document and the template , the automatically- 
generated source code depending on both the markup language document 
and the template, and configured to transform a payload message directly 
between the target program language data format and an online transaction 
processing (OLTP) language message format when compiled and executed ; 

compiling the automatically- generated source code; 

using the compiled automatically- generated source code to transform a 
the payload message directly between the target program language data format 
and the online transaction processing (OLTP) language message format . 

First, the proposed combination of references does not teach or suggest each of the elements 
of claim 1 , as presented. For example, claim 1 recites both "receiving a template for code in 
a program language, the template describing a data format for the message in a target 
program language" and also recites "automatically generating source code in the program 
language from the markup language document and the template, the automatically- 
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generated source code depending on both the markup language document and the 

template, and configured to transform a payload message directly between the target 

program language data format and an online transaction processing (OLTP) language 

message format when compiled and executed." Thus, in the method of claim 1, the source 

code which is automatically generated is created based on both a template and a markup 

language document. In addition, that source code is compiled into program which is itself 

capable of directly translating between two message formats. 

Nothing in either reference discusses automatically generating source code from both 

a template and a markup language document. It is clear that Zorc does not teach or suggest 

such an element and the Office Action does not assert otherwise. Rather, the Office Action 

argues that such a feature may be found in Koch, stating: 

NOTE: Koch reference teaches using both XML (Extensible Markup 
Language) and XSL (Extensible Stylesheet Language) to generate a message . 

[Office Action at 6.] 

Koch, however, uses XSL in an entirely different manner than it is used in the method of 
claim 1 . In Koch, XSL is used as a tool to further alter the format of an XML document, not 
as a template used to generate a code that performs message data conversion. Thus, Koch 
explains that: 

Developers use the XSL language for manipulating XML from one structure 
into another. It can be implemented for transforming XML into HTML or 
other XML document structures (for more information on how to manipulate 
XML documents with XSL, see Resources). 

You will use XSL to format an incoming document structure to the 
name/value -pair structure described above, which the Java code processes into 
the COBOL structure. XSL will also format the data returned from the legacy 
system — once the Java code transforms it back into XML — into a usable 
structure for the function or application using this API. XSL allows you to 
build Java code that will be insulated from changes to the external format of 
both the calling application and the legacy system. I will describe more on that 
advantage later. 

[Koch at 2-3.] 

Explained another way, Koch describes translating a message from the message format of a 
COBOL program into an XML format. Then, Koch suggests individually creating XSL 
stylesheets to further translate the XML format created into another format useful for some 
other system, for example by picking particular fields in the XML format. 
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By contrast, the template of claim 1 is used, together with a markup language 
document, to automatically generate source code for message conversion. Thus, claim 1 
recites "receiving a template for code in a program language, the template describing a data 
format for the message in a target program language." It is here noted that once the source 
code of claim 1 is generated and compiled, the resulting program translates directly between 
message formats; the template itself is no longer needed. The XSL in Koch, however, is used 
to translate between an XML format and an undisclosed format every time a message is 
translated. 

In addition, neither Zorc nor Koch teaches or suggests "automatically generating 
source code in the program language from the markup language document and the template, 
the automatically- generated source code . . . configured to transform a payload message 
directly between the target program language data format and an online transaction 
processing (OLTP) language message format when compiled and executed." The Office 
Action appears to admit that Zorc and Koch do not teach or suggest this claim element, 
pointing instead to a portion of the present application, included within the following 
quotation: 

A typical gaming system includes an application running at the location of the 
consumer, where the application is networked with a remote online transaction 
processing (OLTP) host. The OLTP host is responsible for managing the 
particular game being played and often operates under a proprietary, industry 
specific language. For example, one gaming system, which is commercially 
available from the GTech Rhode Island Corporation, implements an OLTP 
language that defines a specific and unique message structure that results in 
relatively dense byte arrays. The application, on the other hand, is typically a 
web-based program written in an objected- oriented program language, such as 
the Java language, that is incompatible with the OLTP language. Thus, in 
order for the application and the OLTP host to communicate with one another, 
messages between the application and the OLTP host must be transformed 
between the program language of the application and the OLTP language. 
Specialized source code is used to perform the message translation, where the 
source code is developed offline based on the protocols of the two languages. 
Once the message translation source code has been developed, it is used to 
process messages in real-time. There is therefore an offline process in which 
the code is developed, and an online process in which the code is used to 
transform messages in real-time. 

f][ 0005 of the application as published.] 

The quoted paragraph, however, only mentions a custom-coded source code designed to 
facilitate the translation of a message in an OLTP format to the format of a particular 
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application. Nowhere does the section suggest that such code may be generated 
automatically, or discuss how automatic generation could be accomplished. 

Applicants respectfully submit that Zorc and Koch, even combined with the paragraph 
from the present application cited above, simply do not teach or suggest the method recited in 
claim 1. Rather, Zorc generally describes a method which automatically generates code 
designed to translate a message from a first language into a common XML form, and 
contemplates additional code to translate the message in the XML form into another message 
format. There is no teaching or suggestion of automatically translating, or of converting into 
a format specified by another program. Koch also appears to describe translating a message 
from a first format into an XML form and, only then, into an additional message format. 
Koch does not appear to suggest automatically generating any of the code used to perform 
such a translation. In addition, the material referred to as "Applicant's Admitted Prior Art" 
does not teach or suggest automatically generating code of any kind. 

Accordingly, it is respectfully submitted that the proposed combination of references 
does not teach or suggest each of the elements of claim 1, for at least the reasons presented 
above. 

In addition, it is respectfully submitted that the Office Action has also failed to 
demonstrate why it would have been obvious to one or ordinary skill in the art to combine the 
teachings of Zorc and Koch, with the portion of the present application that the Office Action 
terms "applicant's admitted prior art." The only reasoning that the Office Action presents to 
justify the combination is its assertion that: "[t]he motivation is that the messages can be 
exchanged directly between the program language and the OLTP language." Office Action at 
7. But this proposed justification simply uses the itself without even asserting any reason that 
an ordinary artisan would have been led to make the combination. Even after KSR, 
"rejections on obviousness cannot be sustained by mere conclusory statements; instead, there 
must be some articulated reasoning with some rational underpinning to support the legal 
conclusion of obviousness." KSR v. Teleflex, 550 U.S. 398, 82 USPQ2d at 1396. The Office 
Action presents no argument beyond the conclusory statement above. For instance, it 
presents no explanation of how the Zorc and Koch references might be combined with the 
referenced material from the present application. 

Moreover, to the extent the proposed combination is understood, the proposed 
combination appears to totally alter the operation of both Zorc and Koch without explanation 
of how or why this combination would be made to work. If the proposed modification or 
combination of the prior art would change the principle of operation of the prior art invention 
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being modified, then the teachings of the references are not sufficient to render the claims 

prima facie obvious. MPEP 2243.01 (citing In re Ratti, 270 F.2d 810 (CCPA 1959)). 

In addition, both Zorc and Koch expressly teach away from the proposed 

combination. For example, it is the stated purpose of Zorc to facilitate communication 

between different parties by using the standard XML formatted messages as an intermediate 

language. Thus Zorc explains that: 

The Extensible Markup Language (XML) is becoming the de-facto standard 
for describing the format and the meaning of electronic data in a portable way. 
One of XML's most wide spread use is to use XML in communication 
between multiple parties that need to send and receive data among each other 
in order to accomplish a particular task. These parties can be, for example, 
programs or systems. 

[Zorc, at 0004.] 

And also explains that: 

In order for this communication scheme to operate, each party needs to have a 
mechanism for correctly generating and correctly parsing the communication 
messages. It is noted that these tasks are required to be performed by all 
parties involved in the communication regardless of any further specific 
execution performed by a particular party. Typically, each party has a software 
module that converts some kind of internal representation of the data, which 
may be specific for each involved party, to an external representation (e.g., a 
specified communication message in XML format) and vice versa (i.e., 
converts the external representation to an internal representation). 

[Zorc, 0006.] 

Accordingly, it is clear that the actual intent of Zorc is to provide methods only providing 
indirect communication using XML formatted messages as an intermediate format, and thus 
teaches away from Applicant's claim which requires a direct conversion between the message 
formats. 

Koch similarly teaches away from the proposed combination. Just like Zorc the stated 

purpose of Koch is to translate messages into an XML format, not directly between the 

program language format and an OLTP format. Thus Koch states that: 

No matter which way you try it, interfacing a mainframe from an application 
server or servlet is never fun. Among other hurdles to overcome, the 
mainframe could exist on a different platform or use a different character set. 
Think you can simply access the data directly and rebuild your business logic? 
Perhaps, if your database is not hierarchical and you enjoy reinventing the 
wheel. However, a few tricks using XML, XSL, and Java can make it easier 
than you think. 
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XML describes the structure of the data you are sending. Add XSL to 
complete some simple 

transformations. Use Java to encapsulate it with a few simple classes. You will 
then leverage a host of legacy system transactions written decades ago and 
format them into an XML document. Once your data is in an XML format, 
manipulating it becomes a much less daunting task, and development becomes 
easier. In addition, the solution you employ is realtime, which circumvents the 
frustrations and problems that arise from working with an extract file or batch 
interface. 

Again the intent of Koch appears to be to facilitate communication utilizing an intermediate 
message in XML format. Thus, both Zorc and Koch themselves teach away from the 
combination proposed by the Office Action and Applicant's claim 1, suggesting that an 
ordinary artisan consulting Zorc and Koch would not be lead, and in fact would be lead away 
from, contemplating the automatic generation of source code configured to transform a 
payload message directly between a program language and an online transaction processing 
(OLTP) language. Accordingly, it is respectfully submitted that, for at least the reasons 
presented above, the Office Action has failed to present a prima facie case of obviousness as 
to claim 1, and that claim 1 is patentable over the proposed combination of references. 

In addition, independent claims 15, 23, 28, and 32 were amended in a manner similar 
to claim 1 and therefore should be allowable for at least reasons similar to those discussed 
above for claim 1. In addition, claims 3-14 and 36 depend from claim 1; claims 16-22 and 38 
depend from claim 15; claims 24-27 and 40 depend from claim 23; claims 30, 31, and 42 
depend from claim 28; and claims 33-35 and 44 depend from claim 32. It is respectfully 
submitted that the dependent claims are patentable over the proposed combination of 
references for at least the reasons presented above in connection with independent claims 1, 
15, 23, 28, and 32. Withdrawal of the rejection is respectfully requested. 

V. New Claims 46-55 

Claims 46-55 are added herein. The new claims are fully supported by the application 
as originally filed; no new matter has been added. In addition, claims 46-55 depend from 
independent claims 1, 15, 23, 28, and 32. As explained above, the independent claims are 
patentable over the cited references. Accordingly, it is respectfully submitted that the new 
claims are also patentable for at least the reasons presented above in connection with their 
independent claims. 
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Claims 51-55 recite additional features indicating that the source code is configured to 
convert messages from both the OLTP language format to another program language format 
and messages from the other program language format to the OLTP language format. This 
feature is not taught or suggested by the cited art of record. Accordingly, these claims should 
be allowable for at least this additional reason. 
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VI. CONCLUSION 

In light of the foregoing, it is respectfully submitted that all of the presently pending 
claims are in condition for allowance. Prompt reconsideration and allowance of the present 
application are therefore earnestly solicited. While no additional fee is considered to be due, 
the Office is hereby authorized to charge any fees, which may arise out of the filing of this 
paper, or credit any overpayments under 37 C.F.R. §1.16 or §1.17 to the deposit account of 
K&L Gates LLP, Deposit Account No. 080570. 

The Examiner is invited to contact the undersigned at the telephone number below to 
discuss any matter concerning this application. 



Respectfully submitted, 
K&L Gates LLP 



Dated: May 6. 2009 By: / Andrew L. Reibman/ 

Andrew L. Reibman 
Reg. No. 47,893 
K&L Gates LLP 
599 Lexington Avenue 
New York, N.Y. 10022 
(212) 536-3900 (telephone) 
(212) 536-3901 (facsimile) 
CUSTOMER NO. 00545 

Electronic Filing System 



NY-#664263-v3 



-20- 



